Business Analyst Community & Resources | Modern Analyst

What Is Actor Model Architecture?

Adrian M. — Sun, 19 Oct 2025 22:09:00 GMT

The Actor Model Architecture is a software design pattern used to build systems that are highly concurrent, scalable, and resilient. It models computation as a collection of independent entities called actors, each responsible for its own state and behavior.

What is TOGAF?

Adrian M. — Tue, 13 Feb 2024 04:00:00 GMT

TOGAF stands for The Open Group Architecture Framework and is a widely used framework and methodology for enterprise architecture. It provides a comprehensive approach for designing, planning, implementing, and governing enterprise information technology architecture. TOGAF is maintained by The Open Group, a global consortium that develops open, vendor-neutral technology standards which help organizations to achieve their business objectives.

The main components and structure of TOGAF are as follows::

Architecture Development Method (ADM) - This is the core of TOGAF, providing a step-by-step approach for developing and managing enterprise architecture. It consists of a set of guidelines, techniques, and best practices for creating architecture artifacts and managing the architecture development process.

Guidelines & Techniques - This is a collection of best practices which will help the practitioners to adapt the TOGAF Architecture Development Method (ADM) to a number of usage scenarios. These guidelines and techniques include architecture principles, architecture patterns, gap analysis techniques, and much more.

Architecture Content Framework - This is a structured metamodel which defines the types of artifacts and deliverables that should be developed during the architecture development process, such as architecture vision, business architecture, data architecture, application architecture, and technology architecture. It also defines the concept of Architecture Building Blocks (ABBs) as well as Solution Building Blocks (SBBs)

Architecture Capability Framework - This section of TOGAF focuses on operationalizing an architecture function within an enterprise. It defines guidelines for establishing the structure, roles, skills, responsibilities needed for an effective architecture organization within the enterprise.

TOGAF Reference Models - These are generic architectural models and method guidance that can be used as starting points for developing organization-specific architectures. Examples of such models include Architecture Maturity Models, Architecture Project Management, Architecture Skills Framework, Digital Business Reference Model (DBRM), Government Reference Model (GRM), as well as Microservices Architecture.

Mirko Wolff, CC BY-SA 4.0, via Wikimedia Commons

An analyst can use TOGAF in several ways to support various aspects of enterprise architecture development and management:

Understanding Business Needs - Analysts can use TOGAF's Architecture Development Method (ADM) to analyze and document business requirements, stakeholder concerns, and strategic objectives.

Conducting Gap Analysis - TOGAF provides techniques for conducting gap analysis which analysts can use to assess the organization's current state, identify areas for improvement, and define target architectures that address business needs.

Supporting IT Initiatives - Analysts can use TOGAF to support various IT initiatives, such as system implementations, technology migrations, and business process improvements.

Communication and Collaboration - By using the common language and framework defined by TOGAF, analysts can facilitate communication and collaboration among stakeholders, including business leaders, IT professionals, and external partners.

What is a Reliability Block Diagram (RBD)?

Adrian M. — Mon, 12 Feb 2024 06:22:00 GMT

A Reliability Block Diagram (RBD) is a graphical method used in reliability engineering to model the reliability of systems. It represents the components of a system as blocks and their interconnections as lines. The purpose of an RBD is to analyze and understand the reliability of a system by assessing how the failure of individual components or blocks affects the overall reliability of the system.

Reliability Block Diagrams (RBDs) can be relevant to both business and systems analysts, particularly in industries where system reliability is critical, such as manufacturing, transportation, telecommunications, and energy.

What is Domain Driven Design?

Adrian M. — Mon, 11 Sep 2023 01:20:00 GMT

Domain Driven Design (DDD) is not just a buzzword but a very important concept for business analysts and any technology practitioners involved in designing systems and software.

Domain Driven Design is an approach to software design and architecture which, unsurprisingly, starts with an understanding of the problem domain for which the solution must be developed. The DDD approach to software development and design focuses on creating software systems that closely align with and model the real-world domain they are intended to represent.

The first step of Domain Driven Design is to understand the problem domain and create an abstract model of the domain including its entities (nouns), functional (processes), business rules (logic/policies), and key goals and objectives.

There are three core principles of Domain Driven Design:

Focus on the core domain and domain logic - the practitioner must have a solid grasp of the problem domain and must have access to subject matter experts in the given domain

Design must be based on clear domain models - modeling the business domain is a top priority as it enables business experts to validate the practitioner’s understanding of the domain as well ensures corrections in that understanding

Based on ubiquitous language - the language used in the domain models must use language that the domain experts can read, understand, and verify.

Deriving its roots from Object Oriented Analysis and Design (OOAD), the domain driven design approach relies on a number of interconnect concepts including:

Entities and Value Objects - the DDD method distinguishes between entities and value objects. Entities are objects with a distinct identity that is defined by a unique identifier. Value objects, on the other hand, have no distinct identity and are defined solely by their attributes.

Aggregates - An aggregate is a cluster of related entities and value objects that are treated as a single unit. Aggregates have a root entity that serves as the entry point for interacting with the cluster. Aggregates help maintain consistency and enforce business rules within a specific context.

Repositories - Repositories provide an abstraction layer for accessing domain objects, abstracting the underlying data storage and retrieval mechanisms. They enable the separation of domain logic from data access concerns.

Domain Services - Domain services encapsulate domain-specific logic that doesn't naturally fit within an entity or value object. They are stateless and operate on domain objects to perform specific tasks.

Event Sourcing - Event sourcing is a technique where changes to the state of a system are captured as a series of immutable events. This approach allows for reconstructing the system's state at any point in time and provides a historical record of all changes.

Domain Events - Domain events are a way to capture and represent significant state changes within the domain. They can trigger actions in other parts of the system and help maintain consistency.

Domain Driven Design can greatly benefit business analysts by providing them with a structured framework for understanding, modeling, and communicating complex business domains. It encourages collaboration, clarity, and precision in requirements gathering and promotes the development of software systems that closely align with the real-world business needs.

Some of the ways in which domain driven design can help business analysts:

Shared Understanding - DDD encourages the use of a ubiquitous language that is shared between technical and non-technical team members. This common language ensures that everyone involved in the project has a clear and consistent understanding of the domain, its concepts, and its complexities.

Effective Communication - DDD encourages collaboration between business analysts and developers. By using the same domain terminology and concepts, business analysts can communicate requirements, constraints, and domain-specific knowledge more effectively to the development team.

Modeling Business Processes - DDD provides a framework for modeling business processes in a way that aligns with the domain's concepts and rules. This ensures that the resulting software accurately reflects the real-world business operations.

Identifying Domain Entities and Rules - The DDD approach helps business analysts identify domain entities, their attributes, and the rules governing their behavior. This knowledge is essential for defining business requirements and constraints, as well as for ensuring that the software system enforces these rules correctly.

Bounded Contexts - This DDD concept helps business analysts define clear boundaries and contexts for different parts of the business domain. This ensures that each part of the system is designed to serve a specific purpose and that there is a clear understanding of where each boundary lies.

Event Modeling - DDD often involves event modeling, which is useful for capturing important state changes in the domain. Business analysts can help identify and prioritize domain events, as well as define how these events impact the business processes and data flow.

Requirements Elicitation - The DDD methodology encourages a deeper understanding of the domain, which can lead to more precise and well-informed requirements elicitation. Business analysts can leverage this understanding to gather and document requirements that align with the domain's intricacies.

User Story Definition - When defining user stories or use cases, business analysts can use DDD concepts to frame stories in the context of the domain. This ensures that user stories reflect the actual needs and goals of the business and that they are aligned with the domain model.

What is Composable Business Architecture?

Adrian M. — Sun, 10 Sep 2023 22:50:00 GMT

Composable Business Architecture (CBA) is a business architecture approach and methodology that emphasizes flexibility, adaptability, and modularity in designing and organizing the components of a business. It is a response to the ever-changing and complex nature of the business environment, where organizations need to be agile and responsive to rapidly evolving market conditions and customer demands.

“Composable business means creating an organization made from interchangeable building blocks” - Kasey Panetta, Gartner Contributor

The same way a Lego brick is the basic building block of any Lego masterpiece, a Packaged Business Capability (PBC) is the basic building block of a composable business model. Each of the enterprise PBCs fulfills a critical function of the business.

“Composable business is a natural acceleration of the digital business that you live in every day. It allows us to deliver the resilience and agility that these interesting times demand.” - Daryl Plummer, Distinguished VP Analyst, Gartner.

Gartner identifies, four principles of composable business architecture:

Modularity - dividing the business domain into smaller discrete components with clearly defined responsibilities

Autonomy - ensure the individual components are as independent as possible from other components in order to minimize dependencies and enterprise impact when one component needs to be changes or replaced

Orchestration - the process and tools used to control the flow and collaboration among the individual business components in order to achieve specific business objectives

Discovery - the ability to easily find and understand existing business process and component assets within the enterprise to facilitate reusability and for quickly composing new processes for in response to opportunities or business landscape changes

“An organization that delivers business outcomes and adapts to the pace of business change. It does this through the assembly and combination of packaged business capabilities… application building blocks that have been purchased or developed.” — Gartner

When it comes to establishing composable businesses, Gartner defines three essential building blocks, as follows:

Composable thinking - Composable thinking is an adaptable problem-solving approach that involves breaking complex challenges into modular components, allowing for flexible and creative recombination to address evolving needs, fostering innovation and efficiency. It emphasizes modularity, reusability, and customer-centricity in finding solutions and is relevant across diverse domains, including technology, business, and product development.

Composable technology - Composable technology refers to an IT infrastructure and architecture approach that leverages modular components and software-defined resources, enabling organizations to dynamically and flexibly allocate computing, storage, and networking resources to meet specific application or business requirements. This approach enhances agility, scalability, and resource utilization in a rapidly changing technology landscape, allowing organizations to adapt quickly to evolving needs and opportunities.

Composable business architecture - Composable Business Architecture is a strategic framework for designing and organizing a business's components, such as processes, capabilities, and technologies, in a modular and flexible manner. It enables organizations to quickly adapt to changing market conditions, customer demands, and emerging opportunities by promoting modularity, reusability, and interoperability in their business operations.

Composable Business Architecture is particularly relevant in industries characterized by rapid change, digital transformation, and the need for continuous innovation. It helps organizations stay competitive and responsive to emerging opportunities and challenges by providing a framework for designing and organizing their business components in a flexible and adaptable manner.

What is a Flowchart Diagram?

Adrian M. — Mon, 10 Oct 2022 22:52:00 GMT

A flowchart diagram or just flowchart is a term generically used to refer to a diagram which shows the flow of a process (step by step). More specifically a flowchart refers to a very specific type of structured workflow diagram which has been adopted by the International Organization of Standardization (ISO) and updated in 1985 with ISO 5807.

The flowchart is very similar in uses and functions as the UML activity diagram and the BPMN process diagram.

The flowchart diagram is drawn using a set of standard flowchart symbols including:

Symbol Name	Visual Depiction	Description
Flow line		The flowline represents the standard connector of the rest of the symbols in a flowchart. It is terminated with an arrow to show the direction of the flow/process (generally top to bottom or left to right).
Terminal		This flowchart symbol represents either the beginning of the flow or the end of the flow. A flowchart should have only one beginning symbol.
Process		The process flowchart symbol represents an action or activity which takes place at the given step in the process. Generally used to depic an action which takes place in the system or which uses the system.
Predefined Process		The flowchart pre-defined process symbol depicts the fact that this step is decomposed in detail in a different diagram or page. If a given sub-process or segment of a process is reused, it can be defined once and then specified again using the pre-defined process symbol.
Decision		The flowchart decision symbol is very similar to the decision symbol of other diagraming techniques and issued to show where a given process or flow can split into two or more branches based on a decision condition.
Input or Output		This flowchart symbol depicts that at this point in the flow data is either entred into the process/system or data is being output from the process/system.
Manual Input		The manual input flowchart symbol is used to show that a human is performing data entry or providing information to the system.
Data file or Database		The database flowchart symbol is used to depict storage of data (it could be a database, a file, etc.) and it could be used either to read data from or write data to.
Document		The document flowchart symbol represents a single document (ex: PDF, Word, etc.) used within the flow being documented. If multiple documents are used, multiple document symbols can be overimposed and slightly offset.
Manual Operation		The manual operation flowchart symbol is used to show that a user performs a manual operation within the flow which is other than simply data input.
On-page Connector		When a flowchart becomes too complicated and flowlines cross each other, an on-page connector can be used to show where to connect next without crossing lines.
Off-page Connector		When a flowchart becomes too large to fit on one page, the off-page connector symbol can be used to show where the flow leaves off on one page and then where it picks-up on a different page.
Initialization		The initialization symbol represents a step in the process (generally at the beginning) where a certain system routing or processed needs perform preparation/initialization activities.

When to use a Flowchart

Flowcharts are helpful whenever the problem domain you are tackling involves process or workflow or whenever you are trying to depict a structured step-by-step process.

Some example instances when a flowchart would be beneficial:

Document the “as-is” or “to-be” business processes.
Depict the logical flow of an algorithm which needs to be implemented.
Show how a user can interact with a system to achieve a desired objective.
Define the workflow for a given manual activity.

Alternative to Flowcharts

Since the advent of the flowchart, new modeling techniques and standards have been created and which, in many cases, have become more popular than the flowcharts, such as:

Data Flow Diagram
UML Activity Diagram
BPMN Process Flow Diagram
etc.

Example Flowchart

What is the difference between IIBA BABOK tasks "Specify and Model Requirements" and "Define Solution Options", 2 of the 6 tasks covered within the “Requirements Analysis and Design Definition” knowledge area?

Chris Adams — Thu, 09 Jun 2022 21:13:00 GMT

The Specify and Model Requirements Task describes the “What”.

The Define Solution Options Task describes the “How”.

Why bother with identifying use cases? Why not jump straight to process flows?

Chris Adams — Thu, 07 Oct 2021 16:15:00 GMT

Whether documenting business processes or systems processes, use cases and process flows can both be valuable tools.

A use case description textually describes the main success scenarios of a process as well as the major alternate scenarios and exception scenarios. Process flows do the same thing, though in graphical form. A process flow documents the step by step activities of the main success scenario. Decision points (often shown as diamond shapes) show where the main scenario branches off into alternate scenarios.

What is JTBD - Jobs to be Done Framework?

Adrian M. — Sat, 11 Sep 2021 06:37:00 GMT

“Jobs to be Done” also known as JTBD is a market and customer research framework with the goal of identifying the underlying tasks (aka jobs) that customers are trying to get done in the given problem domain.

The Jobs to be Done theory and method was first popularized by Clayton Christensen, Harvard Business School professor, in his very popular book The Innovator’s Solution.

In one of his article titled “Know your Customer’s Jobs to be Done”, Mr. Christensen clearly explains the genesis and core of this concept:

“The theory of jobs to be done was developed in part as a complement to the theory of disruptive innovation—which at its core is about competitive responses to innovation: It explains and predicts the behavior of companies in danger of being disrupted and helps them understand which new entrants pose the greatest threats.”

“What they really need to home in on is the progress that the customer is trying to make in a given circumstance—what the customer hopes to accomplish. This is what we’ve come to call the job to be done.”

To even begin to understand your customer you need to walk a mile in their shoes; you need to understand the jobs they have to do aka their “jobs to be done”. Tasks or jobs are foundational for discovering what motivates your users/customers and why they behave the way they do.

New Markets Advisors, a leading consulting firm in this area, uses a proprietary step by step approach to their Job Roadmap when they apply the Jobs to be Done method to help their customers to innovate:

Establish Objectives -> Strategy

Plan Your Approach -> Research Methods

Build a Jobs Atlas -> Customer Research

Generate Ideas -> Ideation

Reframe Your Perspective -> Open Innovation

Experiment & Iterate -> Test and Learn

Other practitioners take a more traditional approach to jobs-to-be-done by thinking of job as a process which is documented using a Job Map. Basic steps to create a Job Map include:

Define - Define the aspects of the job your customer has a problem with.

Locate - Locate and define the inputs and resources your customer needs to do the job.

Prepare - Identify how your customer must prepare and transform the inputs in order to get the job done.

Confirm - Ask what your customer needs to verify or validate to ensure the job is done right.

Execute - What does the customer need to do to execute the job successfully.

Monitor - Determine what areas or metric your customer needs to monitor to ensure the job is done right.

Modify - What aspects of the job steps need to be changed in order to successfully complete the job.

Conclude - Are there any specific steps which must be completed in order for the job to be final and done?

Business analysts and product managers can use the Jobs-to-be-Done (JTBD) method to create innovative product roadmaps.

How do you ensure that your use case model is effective?

Chris Adams — Fri, 12 Mar 2021 17:38:00 GMT

Use case models include actors and use cases. An effective model must identify both comprehensively. Yet, analysts usually fail to identify all of the relevant actors.

To solve this problem, I like to recommend an approach that maintains a separate use case diagram and actor diagram. Then, the actors from the actor diagram can incrementally be added to the use case diagram as the use case diagram evolves.

How do you gain a sufficient understanding of an industry in which you previously had no experience?

Chris Adams — Mon, 13 Jul 2020 16:00:00 GMT

The Business Entity Model and Context Diagram are two tools that give the business analyst a quick yet sufficient understanding of a new industry. They provide a high-level, overarching view of the space with the least amount of time investment possible.

Why are modeling techniques so important to Business Analysts, and how do you choose the right ones for your project?

Chris Adams — Mon, 08 Jun 2020 17:30:00 GMT

Grouping related items (whether requirements, ideas, business processes, etc.) into a diagram or model is just a way of forming them into recognizable and (hopefully!) familiar patterns. And the short-term memory limit is much less constraining if people are asked to remember and absorb a few different patterns as opposed to dozens of individual bits of information.

How do you ensure all business processes have been accurately identified and captured?

Chris Adams — Sat, 07 Mar 2020 22:21:00 GMT

How can a business analyst ensure that ANY discovery process yields complete results? The short answer is to use multiple complementary techniques to approach a problem from different angles where each validates the other and fills any gaps in the discovery process.

What is Model-Based Management and what benefits can it bring an organization?

Chris Adams — Fri, 06 Mar 2020 22:41:00 GMT

Model-Based Management refers to the activity of managing and making informed decision regarding the future direction of a business, process, or system(s) based on information gleaned and understood from models that document the current state.

What is a logical data dictionary and what are the benefits of maintaining one?

Chris Adams — Sun, 11 Aug 2019 18:00:00 GMT

A data dictionary, also commonly called a metadata repository, is a centralized repository of data elements and other metadata about them. This may include the meaning of a piece of data, relationships to other data, origin, usage, type and length.

What is Business Capability Mapping and why it is beneficial?

Chris Adams — Mon, 12 Nov 2018 19:13:00 GMT

Business capability mapping depicts what a business does to reach its strategic objectives (its capabilities), rather than how it does it (its business processes). Business capabilities are the connection between the business strategy and business execution.

In which document do you include the Class Diagram (business requirements, functional requirements, software specification document)?

sonavi — Mon, 12 Nov 2018 16:20:00 GMT

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

How does Enterprise Analysis bring value to an organization?

Chris Adams — Sun, 13 May 2018 21:43:00 GMT

The information produced through Enterprise Analysis is the basis for critical project decisions – what the project is expected to cost, what value it is expected to bring, whether any solution can be reasonably expected to address the business needs, which solution is the ‘best’ when alternatives are available, and the ultimate decision- should the organization even proceed with a particular project or course of action.

What is a business entity model?

Chris Adams — Sun, 09 Apr 2017 18:00:00 GMT

A business entity model is a logical model that documents the entities, or things, that a business or business process uses and interacts with in order to accomplish its business activities and goals. In addition to documenting entities, a business entity model may capture the attributes of an entity, relationships between entities, and cardinality information. Many business entity models are created in the form of a UML class diagram. However, it is important to note that business entity models document the logical structure of a business domain, not the physical structure.

What are the 5 basic categories of elements in BPMN?

Chris Adams — Mon, 13 Mar 2017 15:25:00 GMT

BPMN is a robust notation designed to balance two competing needs. The notation should be simple enough for all stakeholders to understand, yet robust enough to handle complex orchestration of events to a level of detail which can be made executable. Not an easy thing to do. However, by organizing elements into distinct categories, a sizable notation can be more easily understood.

What types of actions can help the business analyst avoid Analysis Paralysis?

Chris Adams — Sun, 12 Feb 2017 22:10:00 GMT

Analysis Paralysis is the dreaded black hole of projects. So, how do you recognize that you might be in Analysis Paralysis. Here are a few symptoms that might clue you in.

What is the different between a business policy and a business rule?

Chris Adams — Sun, 12 Feb 2017 11:52:00 GMT

Business Rules and Business Policies tend to be complicated for analysts to untangle because they are so closely related. Policies are typically more general assertions or guidance about how an organization is intended to operate, while business rules describe the specific execution of the business policy.

The BABOK describes a policy as “a non-actionable directive that supports a business goal', and a business rule as 'a specific, actionable, testable directive that is under the control of the business and supports a business policy'

The Business Rules Group goes further in their definition of business rules describing it as an atomic statement that defines or constrains some aspect of the business. They categorize business rules as one of three sub-classifications; structural assertion, action assertion, or derivation. The definitions of these get quite detailed and while knowing them, along with understanding things like fact models, may help elaborate one’s understanding of a business rule, at a summary level business rules are best understood by a higher level definition (like the IIBA’s) and a few examples.

Additionally, policies, being more general, typically change less often than business rules which are specific implementations of policies.

To restate, a policy is:

A non-actionable directive
Often requires employees to translate into specific statements of what to do (business rules)
Supports a business goal
Supported by one or more business rules

A business rules is:

Actionable
Specific
Testable
Supports a policy

Examples of policies for a car rental company:

Maintenance must be performed in a manner which maximizes the life and value of the car
Renters must have valid insurance

Example of business rules that may support these policies:

All vehicles are required to have a 58 point inspection after every 3 months of use before re-renting.
A car which has accumulated more than 3500 miles must have its oil changed before re-renting.
Tires with less than 1/16th inch of tread must be replaced.
Renters in the state of Texas must have insurance covering $100,000 of liability or more.
Renters in the state of Arizona must have insurance covering $50,000 of liability or more.

Notice that each of the business rules are written as a level which is actionable, specific, and testable.

--
Chris Adams
LinkedIn Profile

What are the benefits of a developing a business entity model early in the analysis process?

Chris Adams — Sun, 10 Jul 2016 21:00:00 GMT

There are numerous benefits to developing a business entity model (also called a logical data model), early in the analysis process. To understand these benefits, the information captured in the business entity model needs to be understood.

What is a Fact Model?

Chris Adams — Sat, 12 Mar 2016 18:00:00 GMT

A Fact Model is a static model which structures business knowledge about core business concepts and business operations. It is sometimes called a business entity model.

What does the term 'Problem Domain' mean to a business analyst?

Chris Adams — Mon, 08 Jun 2015 14:41:00 GMT

In short, the Problem Domain is anything and everything that is needed to define the area under analysis, fully understand the inputs and outputs of its processes, and achieve the goals of the area under analysis, but nothing more.

What is RML (Requirements Modeling Language)?

Chris Adams — Sun, 10 May 2015 23:02:00 GMT

Requirements Modeling language is a collection of diagrams used to model software from the business analysis or product management perspective.

What information should be included in a logical data model?

Chris Adams — Fri, 06 Jun 2014 04:21:00 GMT

A logical data model is a graphical representation of data that is created or used by the organization, and associated rules governing the structure and relationships of that data. The logical model should use business names (following any established enterprise data or naming standards), and should be independent of any technology or physical design considerations. It typically includes the following information:

Entities (“tables”)

Relationships between entities

Cardinality – the numeric relationship between occurrences of two related entities

Attributes (“fields”) that are relevant to the project. (The logical data model does not include details such as data-types or foreign keys, since those are physical design considerations.)

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is metadata, and why is it important to a BA?

Chris Adams — Fri, 08 Nov 2013 22:33:00 GMT

Metadata is defined as “data about data”. Metadata describes the context, use, and validity of business information. Metadata requirements and definitions are an important part of the data requirements to be captured by the Business Analyst for any new system. Effective collection, maintenance and reporting of metadata support organizational needs to monitor and manage the integrity, quality and accuracy of its data.

Common metadata attributes include the date and time that data was collected or changed, and the data source or identification of the person who performed the change. Metadata attributes for an electronic document or record may include the type of record, its retention period, and its security classification or category.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is OOAD?

Chris Adams — Sun, 09 Sep 2012 16:25:00 GMT

The acronym OOAD stands for Object Oriented Analysis and Design. OOAD is a software engineering approach that models and designs a system as a group of interacting objects. Object is the term used to describe some entity or “thing” of interest. These objects are typically modeled after real world entities or concepts. For the business analyst, these would be the real-world entities that arise within the business (invoice, product, contract, etc).

Objects have attributes which can be set to specific values. This defines the state of the object. Objects also have methods or functions which define their behavior.

Here is a quick example for illustrative purposes. Consider the real world object “Car”. Our car has attributes that can be defined with specific values such as,

make = ford
model = escape
year = 2002
color = green
maximum speed = 130 mph
current speed = 50 mph
ideal tire pressure = 35 psi
current tire pressure = 31 psi
remaining fuel = 12 gallons

Each of these attributes define the “state” of the vehicle. They describe the car as it is at some point in time. Additionally, the car has certain “behaviors” such as

accelerate ()
decelerate ()
refuel ()
fill tires ()

Each of these behaviors of the real world object can be represented as a method of the object when designing the system (methods are also known as a functions in some programming languages). These methods can change the values of the attributes causing a change in state.

OOAD is comprised of two parts:

(1) object oriented analysis

(2) object oriented design

Models of different types can be created to reflect the static structure, dynamic behavior, and run-time deployment of the collaborating objects of a system.

During the object-oriented analysis (OOA) phase object-modeling techniques are used to analyze the functional requirements for a system and create models which reflect the logical design of the system. During the object-oriented design (OOD) phase of the system, models are elaborated upon to include implementation specific details that show how the physical design of the system will come together. OOA focuses on what the system does (its static structure and behavior), OOD on how the system does it (it’s run-time implementation).

Can you depict data items in a business process diagram?

Chris Adams — Sat, 10 Sep 2011 23:11:00 GMT

Data objects and associations can be depicted in business process flow diagrams. BPMN for example defines a specific notation for dealing with data inputs and outputs from activities. The diagram below shows the standard notation used to show a data object which is generated as output from one activity and used as input by another activity.

The BMPN Assocation connector (dotted line with an arrowhead showing the direction of flow), is used to show the data association between the activity which produces the output and the activity which receives and uses the input. If the data within the data object is defined as required, then the activity that relies on the data object as an input cannot proceed until the data is available.

The following diagram shows another allowed “shortcut” notation that can be used when the data object is an output of one activity and an input into the next activity in sequence. However, data objects do not always have to be used as input to the next activity in sequence. They can be used by activity anywhere later in the process.

What is a navigable association in UML?

Chris Adams — Mon, 11 Apr 2011 01:36:00 GMT

Associations are relationships between classes in a UML Class Diagram. They are represented by a solid line between classes. Associations are typically named using a verb or verb phrase which reflects the real world problem domain.

The normal kind of association is bidirectional by default. This means that if an association exists between two classes, then both objects know about each other. However, when creating a UML class diagram it is possible to use a navigable association between two classes. This is shown by adding an arrowhead at one end of the association. If “A” is the source class and “B” is the target class, the arrowhead would be placed on the “B” side of the association. A navigable association of this type means that at runtime object “A” knows about object “B”, but object “B” has no knowledge of or visibility into object “A”.

What is a Swimlane Diagram?

Chris Adams — Sat, 09 Apr 2011 22:42:00 GMT

A swimlane diagram (also sometime called a cross-functional diagram) documents the steps or activities of a process flow or workflow. More specifically, a swimlane diagram groups these activities into swimlanes which are horizontal or vertical columns that contain all of the activities which fit into the category represented by that swimlane. Swimlanes can represent many categories of information such as actors which perform the activities (i.e., role or department), the stage of the process in which the activity takes place, or whatever else the creator of the document feels should be emphasized and communicated by the swimlane diagram. The term swimlane was adopted due to the visual similarity between the horizontal rows of the diagram to that of the swimlanes found within a swiming pool.

A process flow or workflow diagram does not have to use swimlanes. However, since swimlanes communicate additional information about who performs the activity or when it takes place, it’s typically a preferred best practice to include them. Similarly, a swimlane diagram can use only one set of swimlanes (either vertical swimlanes or horizontal swimlanes). In BPMN standards, a process flow is typically shown flowing from left to right. If only one set of swimlanes is used, horizontal swimlanes are most commonly used to group activities. In the UML standard, the activity diagram flows from top to bottom and veritcal swimlanes are most commonly used.

One of the more common choices used by creators of swimlane diagrams is to define the roles which perform each activity within horizontal swimlanes and define the process stages in which the activity occurs within vertical swimlanes.

What is Model-View-Controller?

Chris Adams — Sat, 06 Jun 2009 19:31:00 GMT

What is a View as it relates to system modeling?

Chris Adams — Sat, 09 May 2009 22:06:00 GMT

What is the 4 +1 View Model as it relates to system modeling?

Chris Adams — Sat, 09 May 2009 21:59:00 GMT

The 4 + 1 View Model is a predefined set of views for organizing the design and architecture of a system. It was developed in 1995 by Philippe Kruchten, formerly the Director of Process Development at Rational Software.

The 4 + 1 View Model gets its name from the 4 primary views and 1 supporting view that are used to capture and communicate different aspects of the system.

The 4 primary views are:

Logical View: this view describes the functionality of the system in terms of its static structure and dynamic behavior.
Development View: this view describes the system from a programmer’s perspective and is concerned with the organization of physical code, its main modules, and their dependencies.
Process View: this view focuses on the runtime behavior of the system and the elements of the system that relate to process performance. It includes aspects important to scalability, throughput, and process response times to name a few.
Physical View: this view shows the system from a system engineer's point-of-view. It is concerned with the deployment of software components across the physical architecture including computers and devices , as well as communication between these components.

The 1 supporting view is:

Use Case View: this view describes the functionality of the system from the perspective of external actors.

What is a SIPOC Diagram?

Chris Adams — Sun, 02 Nov 2008 20:42:00 GMT

The SIPOC diagram is a tool that is used to outline the scope of a process improvement initiative (often as part of a Six Sigma improvement project). The tool captures all of the relevant elements of the process under consideration. When used as part of the Six Sigma methodology, it is typically implemented as part of the Measure phase of the DMAIC process. The diagrams name is an acronym for the elements that need to be identified and documented.

S – Suppliers: Who supplies the inputs to the process under consideration
I – Inputs: What are the inputs to the process
P – Process: What are the steps of the process that is being improved upon
O – Outputs: What are the outputs of the process
C – Customers: Who are the customers or beneficiaries of the outputs of the process

One common variation of the SIPOC diagram is to append R (Requirements) to the end of the diagram for additional detail. This is a fairly natural extension of this diagram since the team has identified the customers of the process and can naturally begin to identify the needs of each customer.

To create the SIPOC diagram complete the following steps:

1) List the 5 categories in order (Suppliers, Inputs, Process, Outputs, Customers) across the top of a piece of paper or whiteboard. If you choose to include requirements as a sixth category then you will list it last on the far right of the paper or whiteboard.

2) Begin with the Process column. List and number the highest level steps of the process under the process column header. Keep it to 4-7 high level steps if at all possible. If you would prefer, you can reference a diagram for the high level process and insert the diagram at the bottom of the page.

3) Review each step of the process to identify and document the outputs of the process under the Outputs column.

4) Document the customers that will receive or benefit from each output under the Customers column.

5) Next, identify the inputs that the process requires to properly produce the outputs. Capture these under the Inputs column.

6) Document the suppliers of each input under the Suppliers column.

7) If you chose to include a sixth column for requirements, identify and document the high level requirements that each customer has for the process under consideration. Think about why the process exists. What customer need is it intended to fulfill.

Is it the job of a business analyst or systems analyst to draw the class diagram?

ModernAnalyst.com — Sat, 17 May 2008 06:00:00 GMT

It depends, it depends, and it depends!

As for most questions in business analysis, there isn’t only one answer. Whose job is to create a class diagram depends on the purpose of the class diagram.

First of all, the question implies that there is only one class diagram for a given project: “The Class Diagram”. For the most part, this is not the case. On some projects there may be a multitude of class diagrams while in others there may be none.

Second, the question implies that only one of the person/role on a given project would be task with creating class diagram. This is also not the case! There are many folks (business analyst, systems analysts, developers, etc.) who might have the need to create a class diagram in order to communicate a given concept or to solve a given problem.

So let’s rephrase the question:
“Who would use a class diagram and why?”

The business analyst might chose to create a class diagram in order to model the business domain showing the things of the business (the business domain/industry specific nouns found in the business lingo).

The systems analyst could use a class diagram to develop the logical data model for the system being designed.

The developer may also use a class diagram but for a different purpose: to show the actual classes, interfaces, and types being implemented in a given system.

Why bother developing data models and why in Third Normal Form (3NF)?

Guy Beauchamp — Mon, 10 Dec 2007 20:33:00 GMT

Solutions are processes operating on data. It follows that any change to existing solutions will probably involve changes to processes and data requirements. Process requirements can be expressed in BPMN and many other process modeling notations. Data requirements (as opposed to database design requirements - these are logical requirements that the solution has which are relevant to data and have NOTHING at all to do with database design) model the logical data requirements. Logical data requirements should be expressed in notation that focuses only on the logical data requirement and not the solution that might or might not be used. E.g. classes in UML assume object orientated solutions. Logical data model requirements can be implemented on relational databases, object orientated databases, paper or in someone's head. They are not technology dependant: they just state the logical data requirements that must exit in order for processes to deliver the project objectives.

E.g. A requirement exists to be able to offer add-on sales during the order taking process. The order taking process will change to reflect this. The data requirements mean that items offered for sale also have to have relationships established that represent other items that could be offered as add-on sales for the original item. New data requirements will typically require new processes to maintain the required data logical structure. Modeling the data requirements in 3NF means

1. the minimum amount of data is stored the minimum amount of times.

2. logical inconsistencies are prevented by the data structure itself - e.g. it is impossible to offer a customer postage and packing as an add-on sale item as postage and packing are not related to sale items as add-on candidates.

3. business rules associated with the data will be propagated automatically to any process that attempts to create, read, update, delete (CRUD) that data and do not have to be endlessly repeated by all processes that use the data in the processing logic.

4. data requirements (unlike processing requirements) are relatively stable: while the process for order taking changes every year or so, the fact the company sells items and takes payment does not.

How would you prove that an Entity Relationship Diagram (ERD) was in Third Normal Form (3NF)?

Guy Beauchamp — Mon, 10 Dec 2007 20:25:00 GMT

Third normal form of an ER Diagram (ERD) boils down to every attribute depends on the whole primary key of the entity. Inspect the data model to verify

1. every entity has a business primary key (i.e. a key meaningful to the business, not to the database designers!).

2. no attribute in an entity will vary if the value of another attribute is changed (note: the primary key can not be updated once created).

3. no attributes could ever have null values.

4. there are no repeating groups of attributes in the entity.

There is a data modeler’s joke that you can use to lighten the interview (but not recommended for real world parties!): normalization was (in part) created by Ted Codd - a model is in 3NF when every attribute depends on the primary key, the whole key and nothing but the key - so help me Codd!

Do you feel UML models, or other types of models, have any value once the implementation code has been generated? Why?

Chris Adams — Mon, 24 Sep 2007 21:34:00 GMT

[Be the first to post an answer to this question!]

If you are introduced to a new industry, what steps do you take to become familiar with it and understand it?

Chris Adams — Thu, 20 Sep 2007 01:43:00 GMT

Creating a business entity model can really help increase the pace at which analysts, or anyone else for that matter, come up to speed in a new business industry. Business entity models document the entities, or things, that a business or business process uses and interacts with in order to accomplish its business activities and goals. Therefore, it is an excellent tool for identifying the scope of the business domain and for providing a framework from which the analyst can continue to build and elaborate to increase their knowledge. It helps the analyst quickly identify not only those things that they know about the business but also those things that they don't know about the business.